The WINDOWS driver model (WDM) is a driver technology developed by the MICROSOFT Corporation that supports drivers which are compatible with WINDOWS 98, 2000, ME, XP and WINDOWS SERVER 2003. The WDM is a superset of the WINDOWS NT driver model (NTDM).
In a layered software architecture such as the WDM or NTDM, part of a communications path between a device/logical-unit (LUN) and an input/output (I/O) initiator (e.g., an application on a host connected to the device/LUN via a bus) is a stack of data structures, which in the WINDOWS environment are referred to as device objects (DOs). At initialization (in the WINDOWS environment), the plug-and-play (PnP) manager orchestrates the assembly of (also known as adding drivers to) a stack of drivers that together handle the I/O for a device by successively invoking drivers registered (in the registry of the host) to the type of device, where each driver successively creates then attaches a DO to the top of the stack.
Most drivers are uni-role drivers designed and registered for only one role, i.e., they are invoked to add a DO for only one role. It is noted that a role is a combination of the type of device for which the driver is invoked and the extent of the stack at the point at which the driver is invoked. A driver's function as it relates to the device is implied by the location in the stack of the device object. Different DOs within stack may: handle different aspects of a device's function; provide higher-level conceptual capabilities based on a device's low-level functions; and/or modify information passed between other layers for purposes of modifying or enhancing their behavior.
Unlike uni-role drivers, a multi-role driver is designed and registered for multiple roles. It is to be noted that multi-role drivers are not contemplated by the WDM. When the PnP manager invokes the multi-role driver, no information is conveyed to the multi-role driver as to the role for which it is being invoked. This is because the WDM contemplates only uni-role drivers, i.e., that a driver is invoked only for one role.
The Background Art compensates by providing the multi-role driver with role-discovery code, such as in the system 100 shown in the software block diagram of Background Art FIG. 1. In the system 100, the PnP manager 102 invokes a multi-role driver 104, thereby invoking an AddDevice routine 106 within the multi-role driver 104. Invoking the routine 106 includes passing to it a physical device object (PDO), e.g., A (item 108), as indicated by the arrow 120. Similarly, additional cases of the PnP manager 102 invoking the routine 106 are shown, which includes passing along the PDO B in two different instances (arrows 122 and 124), as well as passing PDO C (arrow 126).
A function is a part of a larger program, e.g., a driver. A function carries out one or more operations which represent a subset of the operations that may be carried by the program of which the function is a part. A routine is a function whose behavior (parameters, return value, intent) is specified by the WDM driver development kit (DDK). An example of a DDK-specified routine is the AddDevice routine.
The AddDevice routine 106 includes a plurality of DOPush functions, each of which generates a DO and adds it to the stack whose base is the PDO. Each of the DOPush functions is specific to a particular role. For the purposes of discussion, it is assumed that the multi-role driver 104 is registered for four roles. Accordingly, the AddDevice routine 106 includes a role(A)-specific DOPush function 112, a role(B1)-specific DOPush function 114, a role(B2)-specific DOPush function 116 and a role(C)-specific DOPush function 118.
In operation, the role-discovery code 110, reacts to receiving a PDO by examining the characteristics of the PDO and (optionally) the extent of the stack to verify that they conform to what the AddDevice routine 206 has been designed to expect. Examining the characteristics of the PDO includes discovering the type of the device which the PDO represents. Examining the extent of the stack includes discovering the point in the build-up of the stack at which the DO is supposedly to be attached by the AddDevice routine 206.
Based upon the discovery of the device type and the extent of the stack, and other characteristics and/or behaviors, the code 110 determines the role for which the AddDevice routine 206 is being invoked. Upon determining the role, the role-discovery code 110 can selectively invoke the corresponding role-specific DOPush function 112, 114, 116 or 118, which includes passing the PDO to the DOPush function.